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ABSTRACT 

This  report  discusses  Che  aspects  of  data  processing  which 
have  hindered  the  Integration  of  operations  research  capabilities 
In  large  decentralized  organizations.  Networking  Is  proposed  as  a 
means  of  promoting  OR  Integration,  the  factors  which  have  Inhibited 
successful  networking  are  dlsctissed,  and  ADP  standardization  Is 
suggested  as  a  means  of  overcoming  existing  limitations. 
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INTRODUCTION 

The  demand  for  larger,  more  comprehensive  operations  research 
(OR)  coiq>uter  programs  has  accelerated  with  the  development  of 
faster,  more  versatile  computing  systems.  Similarly,  the  demand 
for  con^uter  support  In  other  areas  such  as  accounting,  personnel, 
and  statistics  has  also  Increased.  If  the  need  for  ADP  support 
continues  to  grow  at  the  present  rate,  the  majority  of  ADP  users 
may  find  themselves  constrained  by  the  available  computer  support 
at  their  Installation. 

Workload  sharing  was  proposed  as  a  possible  means  of  Improving 
ADP  support  to  customers,  but  Initial  atteiiq>ts  were  frustrated  by 
the  plethora  of  Incompatible  systems,  terminology  differences,  and 
the  variety  of  documentation  techniques  In  use. 

Acting  upon  customer  complaints  of  the  poor  quality  and  high 
cost  of  ADP  support,  the  Bureau  of  the  Budget  recommended  that 
standardization  efforts  be  Initiated  and  that  the  General  Services 
Administration  manage  the  utilization  of  all  government  computers. 
The  result  has  been  a  determined  effort  to  develop.  Implement  and 
enforce  the  utilization  of  standard  procedure-oriented  languages, 
data  elements,  and  documentation  techniques.  At  the  same  time,  the 
General  Services  Administration  (GSA)  was  promoting  compatibility 
In  Its  effort  to  Increase  the  utilization  of  the  data  processing 
facilities  available  to  the  government.  GSA  has  continued  to 
promote  the  utilization  of  workload  sharing  techniques  to  alleviate 
the  overloading  of  certain  facilities  by  transferring  some  of  the 
extra  work  to  under-utilized  data  processing  centers  rather  than 
Increasing  the  size  of  overloaded  facilities. 

If  this  trend  continues,  the  result  could  be  the  develop,  ent 
of  a  workload  sharing  network  concept  which  would  tie  together 
a  number  of  Independent  computer  facilities.  In  order  to  Improve 
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overall  ADP  support  and/or  reduce  tum-around  time.  Successful 
networking  requires  that  additional  standards  and  conventions  be 
developed  so  that  jobs  can  become  facility-independent  and  data 
can  be  stored  In  a  format  and  form  useful  to  a  number  of  users  with 
common  objectives. 

This  general  tendency  toward  networking,  together  with  the 
recent  Congressional  Investigation  Into  the  high  cost  of  Department 
of  Defense  (DoD)  studies,  will  affect  most  Operations  Research  (OR) 
project  leaders  In  the  near  future.  Both  the  DoD  and  the  Department 
of  the  Army  (DA)  have  stressed  the  need  for  the  Integration  of  all 
study  efforts  and  urged  that  comprehensive  standards  be  developed 
which  will  preclude  duplication  of  effort,  reduce  the  time  required 
to  perform  such  studies  and  provide  for  more  usable  results. 

Faced  with  the  ADP  coordination  attempts  of  GSA,  and  the  OR 
Integration  efforts  of  DoD  and  DA,  operations  research  project 
leaders  should  take  the  Initiative  In  addressing  the  following  Issues 

•  the  common  needs  of  the  operations  research  communltv, 

•  the  types  of  standards  that  would  facilitate  the  network 
processing  of  OR  programs,  and 

•  the  factors  which  would  encourage  the  use  of  these  standards. 
PRESENT  SITUATION 

The  growth  of  operations  research  (l.e.,  the  application  of 
mathematical  and  statistical  methods  to  the  study  and  analysis  of 
coiiq>lex  Inter-dlsclpllnary  problems)  was  spurred  by  the  develop¬ 
ment  of  bigger,  faster  computers.  As  these  computers  were  developed, 
more  complex  OR  problems  with  a  larger  number  of  variables  and 
additional  constraints  could  be  Investigated.  In  addition,  as  com¬ 
puting  power  Increased  and  computing  costs  decreased.  It  became 
economically  feasible  for  the  operations  research  analyst  to  examine 
many  problems  which  had  been  neglected  In  the  past.  Hence,  today. 
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we  find  the  Army  performing  OR  studies  In  many  areas  (e.g., 
logistics,  R&D,  material  systems  analysis,  and  management).  As  a 
result,  although  computing  capability  has  Increased  significantly, 
con^uter  users  have  been  more  than  equal  to  the  task  of  utilizing 
this  additional  capability,  leading  to  facility  overloading  and 
tum-around  time  problems  (the  amount  of  tum-around  time  Is  mea¬ 
sured  from  the  time  of  Job  submission  to  the  time  of  receipt  of  the 
job  output). 

Since  the  progress  of  operations  research  projects  appears 
particularly  dependent  on  good  tum-around  time,  and  since  there  is 
such  a  great  demand  for  AOP  support,  the  OR  project  leader  should 
seek  to  alleviate  his  dependence  on  a  particular  computer  facility 
by  developing  machine-independent  programs  and  data  formats  which 
can  be  handled  by  other  coiiq>uter  installations. 

The  factors  which  have  hindered  the  development  of  an  inte¬ 
grated  Army  operations  research  capability  and  the  growth  of  work¬ 
load  sharing  between  data  processing  facilities  which  serve  OR 
customers  are: 

•  the  lack  of  a  central  agency  to  serve  as  a  focal  point 
for  OR  projects, 

•  short-term.  Individualized,  assembly- language  solutions 
to  problems  often  resulting  from  Incomplete  literature 
searches , 

•  the  lack  of  a  library  of  operations  research  programs, 

•  the  lack  of  a  library  of  standard  approaches  to  specific 
classes  of  OR  problems, 

•  the  lack  of  adequate  benchmarks  for  the  comparison  of  the 
many  approaches  to  solutions  of  the  various  classes  of  OR 
problems, 

•  the  problems  of  enforcing  the  utilization  of  a  standard 
documentation  technique. 
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•  the  difficulty  In  developing  standard  data  banks, 

•  the  problems  in  developing  standard  data  element  definitions, 
and 

•  the  lack  of  a  good  vehicle  for  the  dissemination  of  current 
information. 

It  has  not  been  the  Intent  to  say  that  the  items  mentioned 
above  have  been  overlooked.  These  problems  have  been  detected  by 
a  number  of  lower  level  organizations  that  have  taken  a  systematic 
approach  to  the  problem,  producing  a  variety  of  standards.  How¬ 
ever,  a  focal  point  is  needed  to  coordinate  the  attack  on  these 
problems  and  facilitate  the  transfer  of  programs  and  information. 

In  an  attempt  to  disseminate  information  concerning  in-process 
or  recently  completed  studies,  the  Army  Materiel  Command  (AMC)  dis¬ 
tributes  the  very  useful  Cost  Analysis  Monthly  Exchange  (CAME) 
published  bi-monthly  by  the  Comptroller.  The  Comptroller  has  also 
initiated  the  development  of  a  data  base  consisting  of  study  abstracts 
of  all  cost-effectiveness  studies.  After  the  data  base  becomes  opera¬ 
tional,  AMC  Intends  to  offer  a  "key  word"  abstract  search  capability 
which  should  reduce  the  amount  of  effort  presently  required  for  a 
cost-effectiveness  literature  search. Other  sources  of  information 
on  Service-sponsored  studies  are  the  Defense  Documentation  Center, 
the  Defense  Logistics  Study  Information  Exchange,  the  Army  Research 
Office,  and  the  AMC  Missile  Command  (MICOM)  RDTE  scientific  infor¬ 
mation  center. 

All  of  these  facilities  provide  information  on  studies,  but 
they  do  not  serve  as  a  distribution  center  for  OR  programs  or 
techniques,  nor  do  they  attempt  to  evaluate  the  available  opera¬ 
tions  research  approaches  to  specific  classes  of  problems. 

The  importance  of  standard  data  banks  in  the  integration  of 
the  OR  community  cannot  be  over-e]iq>hasized.  A  data  bank  may  be 
defined  as  a  formally  designated  activity  with  the  primary  mission 
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of  centrally  gathering,  processing,  evaluating,  and  storing  data 
to  provide  selected  and  sunsBarized  Information  In  specified  areas. 
The  liiq>lementatlon  of  data  biuiks  Increases  systems  Integration 
since,  although  the  data  Is  accessed  by  many  users.  It  is  updated 
by  only  one  designated  activity.  The  use  of  data  banks  reduces 
the  problems  caused  by  differences  In  lack  of  uniformity  In  data 
element  definition,  data  formats  and  data  file  structure. 

At  present,  the  major  Army  commands  have  established  data 
banks.  In  general,  these  data  banks  do  not  appear  to  be  compatible 
with  each  other  nor  with  the  Department  of  the  Army  data  bank. 

To  combat  this  Incompatibility,  Department  of  the  Army  created 
the  Management  Information  Systems  Directorate,  and  the  Army 
Materiel  Command  has  begun  work  on  the  development  of  common 
data  banks  under  the  NAPALM  project.  A  key  element  of  the  NAPALM 
effort  Is  the  development  of  standard  data  banks  so  that  many 
small  existing  systems  can  be  Integrated.  These  data  banks  will 
permit  the  separation  of  Instructions  from  data  In  a  program,  and 
reduce  one  of  the  major  impediments  to  networking--the  trans¬ 
mission  of  large  quentlties  of  data  to  be  manipulated  by  a  program. 

Since  Congress  hsis  expressed  Interest  in  the  management  ^uld 
cost  of  Service-sponsored  studies,  DoD  has  Issued  the  following 
guidance  to  the  Army: 

•  Each  command  (Army  Materiel  Command,  Combat  Development 
Command,  etc.)  will  consolidate  the  study  efforts  of  Its 
suborganizations  through  a  central  office. 

•  Each  command  will  disseminate  study  Information  among  DA 
staff  agencies  and  other  major  commands  to  facilitate 
project  coordination  and  the  development  of  a  rapid  compre¬ 
hensive  response  In  support  of  study  programs. 
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DoD  has  pointed  out  that  these  measures  will  minimize  the 
possibility  of  a  contractor's  performing  the  same  study  for  dif¬ 
ferent  agencies  and  will  promote  Increased  effectiveness  In  the 
management  of  ongoing  projects. (2) 

The  GSA  Is  responsible  for  maximizing  the  utility  of  all 
government  computers.  However,  since  the  primary  mission  of  each 
computer  facility  Is  to  provide  data  processing  support  to  Its 
host  agency,  the  data  processing  support  capabilities  of  the 
Services  are  not  being  utilized  as  a  total  Integrated  resource. 

Poor  ADP  support  to  the  customer,  duplication  of  effort,  and  less 
than  optimum  utilization  of  the  total  data  processing  support 
capability  (the  overloading  of  some  ADP  facilities  while  others 
are  under-utilized)  are  the  result  of  this  lack  of  coordination. 

As  a  result,  GSA  Is  Interested  In  promoting  workload  sharing 
and  program  exchange  between  data  processing  centers.  Since  the 
utilization  of  these  techniques  should  reduce  OR  study  costs 
and  liig>rove  turn- around  time,  the  operations  research  project 
leader  should  be  Interested  In  effecting  workload  sharing  and 
program  exchange. 

WORKLOAD  SHARING  AND  PROGRAM  EXCHANGE 

Workload  sharing  may  be  defined  as  the  transmission  (either 
manually  or  automatically)  of  a  discrete  "job"  entity  to  another 
ADP  Installation  for  execution.  Program  exchange  Is  the  exchange 
of  techniques,  subroutines  or  complete  programs  which  can  be  used 
without  Incurring  the  expense  of  additional  modification. 

Here  are  some  examples  of  workload  sharing  between  Instal¬ 
lations.  In  1966,  the  Ground  Combat  Communications  Simulation 
was  run  at  Fort  Huachuca,  Arizona,  to  satisfy  a  contract  let  by 
the  systems  analysis  group  at  Fort  Monmouth,  New  Jersey.  Recently, 
the  U.  S.  Army  Management  Systems  Support  Agency  has  leased  time 
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from  the  Department  of  the  Interior. Although  the  extent 
of  program  exchange  Is  difficult  to  determine.  It  Is  evident 
that  It  has  been  hindered  In  the  past  by  documentation  limitations, 
assembly  language  limitations  and  the  preference  of  programmers 
to  develop  new  programs  rather  than  modify  existing  programs. 

The  full  benefits  of  workload  sharing  and  program  exchange 
have  not  been  realized  because  of  compatibility  limitations  which 
arise  due  to: 

•  different  hardware, 

•  different  software, 

•  different  operational  procedures, 

•  dissimilar  data  formats  and  a  variety  of  definitions  of 
data  elements, 

•  geographic  separation  of  Installations  (under-utilization 
of  communication  facilities) ,  and 

•  security. 

Compatibility  means  the  ease  with  which  a  program  running 
on  one  system  can  be  transferred  to  another,  or  data  generated 
In  a  particular  system  format  can  be  utilized  by  another  system. 
Compatibility  may  be  discussed  then  In  terms  of  hardware  dif¬ 
ferences,  software  differences,  operational  procedure  differences, 
and  data  format  differences.  Two  other  major  limiting  factors, 
geographic  separation  of  Installations  and  security,  are  Inter¬ 
twined.  As  communication  facilities  are  developed  primarily  for 
transmitting  data  and  as  better  cryptographic  devices  are  produced, 
these  factors  will  become  less  of  a  problem. 
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In  general,  data  processing  Installations  use  Incompatible 
hardware  and  are  configured  differently.  In  the  past,  computer 
manufacturers  have  not  atteoq>ted  to  develop  systems  which  were 
fully  compatible  with  those  produced  by  competitors.  Furthermore, 
only  with  the  advent  of  third-generation  equipment  did  Intra-system 
compatibility  (coiiq;>atlblllty  among  systems  produced  by  the  same 
manufacturer)  become  Important. 

It  has  been  suggested  that  the  development  of  the  proper  type 
of  software  would  eliminate  compatibility  problems.  However,  one 
should  remember  that  the  objective  of  each  computer  manufacturer 
to  promote  compatibility,  but  to  maximize  the  sales  of  his 
-achlnes.  Since  processing  capability  depends  upon  both  hardware 
and  software.  It  may  be  assumed  that  the  manufacturer's  software 
Is  designed  to  complement  his  hardware.  Thus,  even  though  the 
objective  of  each  manufacturer  is  the  same,  a  variety  of  software 
packages  exists. 

Basic  software  differences  exist  In  the  areas  of  operating 
systems  and  languages.  Each  manufacturer  provides  a  specific 
operating  system  to  be  used  with  his  hardware.  These  operating 
systems  offer  widely  differing  services  In  the  areas  of  procedure- 
oriented  language  and  utility  support,  hardware  support,  file 
management  and  Input/output  control,  systems  services  2uid  job 
control.  In  general,  some  compatibility  exists  among  systems  of 
a  series  developed  by  a  single  manufacturer,  but  there  is  no 
coiiq>atlblllty  across  manufacturing  lines.  In  fact,  operating 
systems  and  their  functions  have  not  been  fully  defined. 

All  manufacturers  provide  assembly  languages  to  be  used  with 
their  systems.  These  languages  differ  extensively  with  regard 
to  the  size  and  nature  of  the  Instruction  sets  and  optional 
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features  which  are  provided.  Since  these  languages  were  designed 
for  system  optimization,  the  lack  of  compatibility  among  assembly 
languages  Is  not  surprising. 

Procedure-oriented  languages  (POLs)  such  as  FORTRAN  (the 
de  facto  scientific  programming  standard)  and  COBOL  (the  standard 
commercial  programming  language) ,  were  developed  to  facilitate 
programming  and  ease  system  conversion  problems.  Since  program¬ 
mers  were  able  to  work  with  a  language  that  was  theoretically 
Independent  of  the  machine,  the  concept  of  compatibility  was 
promoted.  However,  only  within  the  past  three  years  has  the 
American  Standards  Institute  sanctioned  standard  specifications 
for  FORTRAN  and  COBOL,  and  today  many  existing  computer  systems 
use  coiiq>llers  which  deviate  from  the  USASl  standard.  These  non¬ 
standard  features  Include  both  restrictions  and  extensions  to 
the  standard  specifications  so  that  additional  programming  capa¬ 
bility  or  greater  computer  efficiency  Is  provided.  In  general, 
these  deviations  prevent  a  POL  program  developed  for  one  system 
from  rimnlng  on  another  system  without  modification. 

Data  compatibility  as  such  does  not  currently  exist.  Existing 
data  banks  are  machine-dependent,  because  systems  Integration 
was  not  a  main  design  point  at  time  of  Installation.  The  basic 
data  definitions,  data  formats,  and  data  structures  were  designed 
to  satisfy  Internal,  not  external,  requirements.  This  has  nec¬ 
essitated  the  development  of  either  special  data  bases  or  special 
programs  for  format  translation  to  satisfy  reporting  and  Inter¬ 
face  requirements.  Standard  means  of  describing  data  elements 
and  standard  approaches  to  data  bank  development  must  be  provided 
so  that  common  Information  needs  may  be  planned  for. 
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In  sinmnary,  the  OR  user  (as  well  as  other  users  dependent 
on  ADP  support)  faces  long  tum-around  times  In  the  future. 
Workload  sharing  through  networking  appears  to  be  a  possible  solu¬ 
tion  to  the  OR  user,  but  compatibility  problems  presently  restrict 
Its  usefulness.  These  coiQ>atiblllty  problems  are  due  to  confi¬ 
guration  differences,  data  format  differences,  and  the  use  of 
different  versions  of  the  applications  language. 

FUTURE 

In  order  to  better  utilize  the  data  processing  support 
available  to  the  government,  to  liqtrove  tum-around  time,  and  to 
reduce  the  time  required  to  respond  to  study  directives,  some 
type  of  networking  will  probably  be  Implemented  in  the  future. 
Networking  (the  step  beyond  program  exchange  and  workload  sharing 
In  the  evaluation  of  a  coiq> rehens Ive,  efficient  overall  ADP 
support  capability)  is  a  technique  by  which  a  number  of  data 
processing  systems,  linked  by  data  communications  lines,  are 
utilized  to  provide  Inqiroved  data  processing  support  for  the 
linked  Installations.  In  this  manner,  the  extremes  of  under¬ 
utilization  and  overloading  of  Installations  can  be  avoided. 

The  benefits  of  networking  are: 

•  Improved  capability , 

•  Increased  availability  of  resources, 

•  Improved  operational  efficiency, 

•  Improved  ADP  backup  c^ablUty,  and 

•  possibly  reduced  ADP  support  costs. 

Before  networking  becomes  a  reality,  however,  techniques  must  be 
developed  which  permit  Interleaving  of  shared  files,  facilitate 
error  Isolation,  and  provide  both  data  and  program  security. 

These  problems  are  currently  being  attacked. (^) 


In  addition,  a  greater  degree  of  program  compatibility  Is 
necessary  and  further  data  compatibility  Is  desirable.  Program 
compatibility  may  be  effected  by  either  using  common  hardware  and 
software  or  by  development  of  a  standard  Interface  between  computer 
systems.  In  either  case,  standard  programming  languages,  such  as 
USASl  FORTRAN  and  USASI  COBOL,  will  play  a  vital  role,  as  will 
the  USASCll  standard  code.  These  standards  will  help  bind  the 
various  ADP  Installations  Into  an  Integrated  data  processing 
resource.  With  the  growth  of  common  data  bases.  It  will  become 
feasible  to  separate  Instructions  from  data  In  a  program  with  the 
eventual  result  being  the  elimination  of  the  expensive  transfer 
of  large  amounts  of  data  between  data  processing  Installations 
and  further  Integration  of  ADP  resources. 

To  effect  the  Integration  of  ADP  facilities,  additional 
standards,  such  as  user  rules  and  data  conventions,  must  be 
developed.  Examples  of  user  rules  are: 

•  general  naming  conventions  for  files.  Items,  and  solution 
techniques  to  Increase  understanding  and  reduce  misinter¬ 
pretation, 

•  restrictions  on  the  use  of  mixtures  of  languages,  espe¬ 
cially  assembly  languages,  and 

•  establishment  of  rules  to  Indicate  when  various  types  of 
standards  are  appropriate. 

Data  conventions  are  the  fundamental  standards  which  make 
data  exchange  possible. (^)  They  Include; 

•  standard  definitions  of  data  elements, 

•  standard  data  names, 

•  standard  definitions  of  values, 

•  standard  terminology,  and 

•  standard  data  file  structures. 


EFFECT  (W  THE  OR  COMMUNITY 

The  OR  communlcy  should  be  Interested  in  both  program  stan¬ 
dardization  and  data  standardization  because  the  OR  scope  of  effort 
takes  in  both  developmental  and  experimental  programs  with  small 
data  bases  and  production  programs  which  manipulate  large  quantities 
of  data  developed  by  different  agencies.  Flexibility  Is  gained 
If  machine-independent  languages  are  utilized  In  new  program 
development,  because  the  program  can  be  run  at  any  network  link. 
Similarly,  If  data  banks  are  built  according  to  generalized 
standardized  concepts,  only  the  program  will  have  to  be  transmitted 
since  copies  of  the  most  utilized  data  bases  can  be  kept  at  each 
network  link;  thereby  also  Increasing  flexibility. 

If  operations  researchers  support  and  contribute  to  these 
standardization  efforts,  an  Integrated,  more  effective  OR  community 
should  result.  Duplication  of  effort  should  decrease  and  Information 
Interchange  between  operations  research  analysts  with  similar 
problems  should  Increase.  Therefore,  less  time  should  be  wasted 
on  unproductive  efforts  and  more  time  can  be  devoted  to  original 
research. 

Report  generation  should  become  easier  for  the  operations 
research  analyst  because  the  need  for  building  special  programs 
to  translate  formats  or  modify  data  bases  to  satisfy  reporting 
requirements  should  diminish.  At  the  same  time  management  will 
benefit  In  that: 

•  The  development  of  long-range  plans  will  be  easier  because 
summarized  management  Information  will  be  available  on 
current  OR  projects  according  to  category. 

•  Better  guidance  should  result  because  a  common  approach  to 
planning,  review,  and  analysis  will  be  feasible. 
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CONCLUSIONS 


The  OR  user  may  object  that,  although  standardization  and 
centralization  may  be  useful,  it  Is  not  his  function  to  develop 
standards.  This  may  be  true.  However,  as  networking  concepts 
are  Increasingly  utilized  to  liiq>rove  the  quality  of  ADP  support, 
additional  standardization  will  be  necessary.  Thus,  the  OR 
community  will  greatly  benefit  by  contributing  to  the  development 
of  standards,  rather  than  being  forced  to  accept  unrealistic  or 
useless  standards.  It  Is  hoped  that  the  OR  community  will  re¬ 
cognize  the  need  for  further  analysis  of  both  program  and  data 
standardization  needs  and  appoint  an  ad  hoc  group  to  determine 
the  desirability  of: 

•  Enforcement  of  a  standard  documentation  technique, 

•  Development  of  a  library  of  operations  research  programs, 

•  Development  of  a  library  of  standard  approaches  to 
specific  types  of  OR  problems, 

•  Development  of  standardized  and  generalized  program 
design  techniques  to  prevent  Individualized  short-run 
solutions  to  new  types  of  OR  problems, 

•  Joint  program  development  by  the  major  Anoy  commands  or 
joint  program  development  with  the  Navy,  Air  Force,  and 
NASA  on  similar  types  of  problems, 

•  Definition  of  specific  types  of  OR  problems  aa  candidates 
for  standardization, 

•  Development  of  benchmark  problems  for  the  comparison  of 
alternative  approaches  to  the  solution  of  the  various 
types  of  OR  problems,  and 

•  Development  of  a  monthly  and  newsletter  or  publication 
dedicated  to  the  dissemination  of  Information  on  current 
operations  research  projects. 
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Common  mathematical  and  statistical  algorithms  and  standard 
approaches  to  the  solution  of  specific  problem  types  should  be 
effected.  The  capability  of  breaking  large  programs  Into  segments 
to  be  run  at  separate  facilities  and  the  growth  of  central  data 
banks  will  become  a  reality. 

As  an  example  of  some  of  the  benefits  to  the  OR  community 
from  Increased  standardization,  consider  the  present  situation 
which  exists  In  deployment  planning  In  DoD.  Deployment  planning 
Is  the  allocation  of  transportation  and  logistics  resources  so 
that  operations  will  be  optimized.  Presently,  the  Army,  Navy, 

Air  Force,  and  Marine  Corps  have  developed  different  resource 
allocation  models  for  deployment  planning,  and  deployment  monitoring. 
Since  different  techniques,  assumptions,  constraints  and  data 
formats  are  utilized  by  the  Services,  it  is  extremely  difficult 
for  JCS  to  Integrate  the  results  of  the  Service  programs  into  a 
comprehensive  DoO  program.  Since  the  Service  programs  and  data 
formats  are  different,  they  do  not  provide  a  backup  capability 
for  each  other  and  the  development  of  Integrated  data  banks  has 
been  restricted.  It  Is  hard  to  Justify  such  conditions  and  the 
resultant  loss  of  flexibility. 

Similarly,  the  trajectory  estimation  requirements  of  the  Armed 
Forces  and  NASA  are  quite  similar.  The  Air  Force  Eastern  Test 
Range,  TDi,  and  Autonetlcs  (TRW  and  Autonetlcs  provide  system 
engineering  support  for  the  Minuteman  111  project)  have  developed 
trajectory  estimation  programs  which  are  utilized  by  the  Air  Force; 
Lockheed  has  solved  this  problem  for  the  Poseidon  missile  tests 
and  Lockheed  developed  another  program  for  NASA's  Saturn  project. 

All  solutions  produce  similar  results.  This  problem  area  appears 
to  be  one  In  irtilch  great  savings  would  accrue  If  standardized  and 
generalized  system  design  and  documentation  techniques  were  utilized. 
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